1 Use of a Job Ticket Service to Store Bid Information 

2 Technical Field 

3 The technical field is the rtitegration and control of services in a networked environment. 

4 Background 

5 Services may be provided by one or more operating units in a computer-based network. 

6 Users of the network may generate specific tasks and send the tasks into the network to be 

7 assigned to one of the operating units. For example, a user at a computer terminal may generate 

8 aprinting order using a printer driver installed on the terminal. The printer driver is used to control 

9 the printing request. In another example, a user at a computer terminal may generate a printing 

1 0 order and send the printing order into a computer network so that the printing order is completed 

11 by aprinting service. The printing order may be related to a company brochure. The printing order 

1 2 may contain unique requirements such as paper type, font size, layout, graphics, color, and other 

1 3 requirements. The user may specify that a specific printing service, such as Kinkos, prepare the 

1 4 company brochure. Alternatively, the computer network may include programs that suggest 

15 printing services to the user. 

16 To control the printing job, the user's computer terminal may generate a job ticket. The 

17 job ticket includes the requirements, such as the requirements listed above, and an identification of 

1 8 the specific job that allows the job status to be tracked through the computer network. 

1 9 Use of the j ob ticket allows printing and similar services to be allocated to those resources 

20 (i.e., the operating units) that are best suited to completing the services. Unfortunately, current 

2 1 computer systems do not allow access to the wide variety of services existing in networked 

22 computer systems, such as the Internet. In addition, current systems require users to have some 

23 knowledge of the existing resources, and may require users to include applicable programming to 

24 communicate with the services. Furthermore, current systems do not allow a j ob request to be split 

25 among several processors. As a result, completion of the job request may take longer than 

26 necessary, and may not be completed in the most efficient, lowest-cost manner. 

27 Summary 

28 To overcome these and other problems related to use of a j ob ticket, a method and an 

29 apparatus allow a client to managejob attributes and processes using an electronic service. The 
3 0 service uicludes aj ob ticket service that allows access and modification of a job ticket by multiple 
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1 users on a network. The method and apparatus use a network-accessible j ob ticket to relate to 

2 a specific j ob or content. The j ob ticket may be an obj ect, such as an XML object, comprising 

3 routines and data. The content may be stored on the network and may be accessed by multiple 

4 jobtickets. Storage and management ofthejob ticket are transparent to the user. Thejobticket 

5 is stored in a common location in the network. The job ticket remains in the same location in the 

6 network, and users access only that portion of the j ob ticket required to complete a designated 

7 process. Security measures may be added to limit access to those users designated as being 

8 allowed to access the job ticket and the job file. The job ticket may include a service ID that 

9 relates the job ticket backto the originating job ticket service. In this way, a user who acquires all 

1 0 or part ofthejob ticket can refer back to the originating j ob ticket service (and the original, or as- 

1 1 modified, job ticket) to verify any changes and to ensvire that the job ticket being accessed is up-to- 

12 date. The job ticket also includes a job ID to refer the job ticket to a specific job. 

1 3 The service is coupled through a communications network to a fi-ont end service. The fi'ont 

1 4 end service allows a user to generate a service or j ob request. The commimications network may 

15 be the Internet, or a local area network, for example. 

1 6 The service includes a service bus, to which are coupled a j ob store, the j ob ticket service, 

1 7 and a work flow controller. Also coupled to the service are one or more processors that may be 

1 8 controlled to complete processes and tasks defined in the job tickets. 

1 9 The job ticket service may generate and store thejob tickets. Job content (e.g., aPDF file) 

20 is stored in thejob store. With this structure, the user does not have to manage storage ofthejob 

2 1 content or to know which j ob store holds the job content. The j ob ticket service controls access 

22 to thejob tickets, and, through the use of thejob tickets, also controls access to job content in the 

23 job store, or elsewhere in the network. Thejob ticket service may create a reference to thejob 

24 ticket, and may use the reference to control access to the job ticket. 

25 By using the service, a user may access a wide variety of services (processors) that are 

26 coupled to the service . The service may arbitrate among the processors to determine an optimum 

27 selection of processors to complete the tasks specified in the user' s j ob request. The service 
2 8 handles the necessary interfaces and program conversions required to allow task completion by the 

29 selected services. In this way, the user need not have any knowledge of the operating requirements 

30 of the processors. 
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1 A bidding service may be used to receive bid information from processors coupled to the 

2 service center. The processors submit bids in response to posting of job ticket notices at the 

3 service center. In an embodiment, the j ob ticket notice is a separate obj ect stored in the service 

4 center. In another embodiment, the j ob ticket itself serves the notice function. The work flow 

5 controller may post the j ob ticket notices after receipt of the j ob request. Whether the bidding 

6 service or the work flow controller receives the bids, the bid evaluation and selection process may 

7 be the same. 

8 The job ticket notice posted by the work flow controller may include specific tasks or 

9 branches that must be completed to complete the job request. The job ticket notice may include 

1 0 descriptions of specific branches and their interrelationships in sufficient detail to allow the 

1 1 processors to bid for completion of the branches. 

1 2 The bidding service may select bids from the processors based on set criteria. For 

1 3 example, the job request may specify rnidmvim performance requirements (e.g., amaximum cost 

1 4 and a completion deadline). The bidding service may rej ect any bids that fail to satisfy the minimum 

1 5 performance requirements . When the work flow controller has estabhshed multiple branches, each 

1 6 such branch may include minimum performance requirements. The branch-specific performance 

1 7 requirements may be established by the work flow controller based on overall performance 

1 8 requirements for the j ob ticket. 

1 9 Description of the Drawings 

2 0 The detailed description wiU refer to the following figures in which Mke numerals refer to like 

21 items, and in which: 

22 Figure 1 is a block diagram showing a prior art use of a job ticket; 

23 Figure 2 is a tree diagram showing the processes in an example job ticket; 

24 Figure 3 is a block diagram of a digital image work flow network; 

25 Figure 4 is a block diagram of a service center used with the network of Figure 3; 

26 Figures 5A-5D illustrate an exemplary job ticket; 

27 Figure 6 is a diagram of functions controlled by a job ticket service; 

28 Figure 7 is a diagram showing access functions controlled by the job ticket service; 

29 Figure 8 is a block diagram illustrating additional control features of the job ticket service; 
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1 Figure 9 is a flow chart illustrating one of the processes controlled by the j ob ticket service; 

2 and 

3 Figures 1 0- 1 5 are flow charts showing sub-processes in the overall process illustrated in 

4 Figure 9. 

5 Detailed Description 

6 Figure 1 is a block diagram showing a prior art application of a j ob ticket service . Job 

7 tickets are often associated with a printing standard, the j ob definition format (JDF). The JDF is 

8 described in detail in JDF Specification Draft Spiral 4.0, available at www.hp_opensoiirce. com. 

9 which is hereby incorporated by reference. Li Figure 1 , a user 1 generates a j ob request and sends 

1 0 the job request through a portal 4 to aprocessor 5 . The j ob request may include ajob ticket data 

11 file 2 and a content file 3 . The user 1 may be a computer terminal in a networked computer system 

12 and the processor 5 may be a networked printer. The job request may involve printing a 

1 3 document. The document may be represented by the content 3 , which is a digital representation 

1 4 of text and images to be printed. The intended format of the printed document may be described 

15 in the j ob ticket file 2 , which is simply a digital file that specifies how the printer is to print the 

1 6 document. For example, the j ob ticket file 2 may require that the document be printed on back-to- 

17 back pages. 

18 In a specific application, the fiinctions of the j ob ticket file 2 may be carried out by a printer 

1 9 driver. The printer driver encodes control data related to printing the document, and sends the 

20 control data and the content 3 to the printer (i.e., the processor 5). The printer accesses the control 

21 data and the content 3 to print the document. 

22 While the application shown in Figure 1 works well to print a document, the application has 

23 many drawbacks. In particular, if multiple processors are involved in producing the document, 

24 each such processor will require access to the job ticket file 2. This access brings problems related 

25 to security, modification control and workflow control. For example, each processor requiring 

26 access to the j ob ticket file 2 may have to wait on processing until aprior processor has completed 

27 use of the job ticket file 2. Thus, the prior art application may result in unwanted delays in 

28 completing the job request. 

29 Prior art applications of job ticket services also suffer because the user may not know 
3 0 anything about the processors, including capabilities and availabilities of the processors, or even if 
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1 the processors exist. Thus, the user may not know which portal to use to connect to a specific 

2 processor. 

3 These and other problems are solved by a method and an apparatus that controls access 

4 to a job ticket and associated content through use of a job ticket service. The j ob ticket service 

5 includes mechanisms that arbitrate access to the job ticket among multiple users of the job ticket, 

6 limit access to the job ticket by incorporating security features, and ensure modifications made by 

7 one processor or user are reflected in the job ticket and the content. In effect, the apparatus 

8 includes a generic database that couples input data from clients as job requests with output services 

9 such as processors that perform tasks or processes to complete the j ob requests. The database 

1 0 may have the features of a generic XML database in that it is extensible, and in that the clients need 

1 1 not have any knowledge of the individual processes to be performed, or the internal programming 

12 requirements of the processors. Thus, the clients may submitjob requests to a service center that 

1 3 will ensure that an appropriate processor or processors are assigned to complete the j ob request. 

1 4 Before describing the apparatus and method in detail, a review of a j ob ticket is provided. 

1 5 Figure 2 is a node-tree diagram (or simply a node tree) 1 0 that illustrates processes defined in a 

16 jobticketforprintingabrochure. The brochure may be printed on a commercial press, andmay 

1 7 use digital content to generate plates for printing the brochure. Within the node tree 1 0, the nodes 

1 8 specify a product, process, or group of processes. Each node may modify, consume or create 

1 9 resources. Each node may contain ftirther nested nodes, or sub-nodes . The arrangement of nodes 

20 and sub-nodes may be likened to a tree, and each node and sub-node may be referred to as a 

2 1 branch. A brochure node 1 1 defines the features and parameters of the brochure. A cover node 

22 12 defines the parameters for producing the brochure cover. Inside pages node 1 3 includes the 

23 parameters to produce the inside pages. The inside pages node 1 3 is shown with several sub- 

24 nodes, including a sub-node 1 4 for digital plate making. The digital plate making sub-node 1 4 itself 

25 includes two additional sub-nodes, a ripping sub-node 16 and a plate making sub-node 18. 

26 Each of the nodes and sub-nodes shown in Figure 2 has associated with it input resources 

27 and at least one output resource. A resource maybe describedbyparameters or logical entities. 

2 8 The resource may be a physical entity such as a component, a handling resource, or a consumable. 
29 A component resource may be the output of a node or sub-node, such as a printed sheets. A 

3 0 handling resource is used during a process, but is not consumed by the process. A consumable 
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1 resoiirce may be partly or wholly consumed by the process . Examples of consumable resources 

2 include inks, plates, and glue. Other resources may be a digital file or representation of a physical 

3 object. For example, the ripping sub-node 16 may include as input resources a run list, media, RIP 

4 parameters, and layout. The nin list resource describes the pages, including the files in which the 

5 pages occur, and which pages are to be used. The media resource describes the media that will 

6 be used to make plates, and is needed to describe the dimensions of the media. The RIP 

7 parameters resource describes all device-specific parameters of the ripping process. The layout 

8 resource describes placement of source pages onto the plates, and eventually onto press sheets . 

9 As an output resource, the rippmg sub-node 16 may provide ripped flats. Other resources include 

1 0 parameter resources, which define the details of processes, as well as other non-physical computer 

1 1 files used by a process. 

1 2 The node tree 1 0 shown in Figure 2 is intended to apply to printing a document. However, 

1 3 node-tree diagrams may be used to represent job tickets for other services besides printing. For 

1 4 example, a j ob ticket may be used for data processing, image processing, creating and mamtaining 

1 5 a database, electronic publishing, e-mail, and various e-commerce services. Moreover, the j ob 

16 ticket may be used to allow different e-commerce services to interact with each other. 

17 Figure 3 is a block diagram of a digital imaging work flow (DIW) network 20 that 

1 8 incorporates a service center and ajob ticket service to control tasks submitted by clients. The 

1 9 service center may operate as a single portal through which the clients connect to one or more e- 

20 services including e-mail, e-commerce and online shopping, e-printing, and data services, including 

2 1 database searching and database construction, population and maintenance. Using a single portal, 

22 such as the service center, allows the clients to select fi-om a wide variety of e-services, such as 

23 those noted above, without requiring the clients to have any prior knowledge of the e-services. 

24 The service center may include components that receive information in the form of job 

25 requests, and using the information, create a j ob ticket that specifies tasks and resources. The j ob 

26 ticket may be stored in ajob ticket service, and notices may be posted to indicate when ajob ticket 

27 is available. Processors coupled to the service center may bid on completion of the job ticket, and 

28 the service center may include a bidding service that evaluates bids. The service center may select 

29 one or more processors to assign to the job ticket based on client-supplied criteria, or based on 

30 a set of standard criteria, including industry standard criteria. The service center may provide 
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1 mechanisms to control access to the job ticket, or to portions (branches) of the job ticket. The 

2 mechanisms include branch locking, and authorization and authentication servers that use public key 

3 encryption, or similar processes. 

4 The service center may include hardware components such as servers, computers, central 

5 processing units, communications interfaces, and memory devices to provide the processing 

6 capability and data storage required to carry out the above-described functions. 

7 The DI W network 20 includes a front end service 3 0 that allows a cHent 3 1 to generate 

8 and submit a service or job request 32 (shown in Figure 7). In an embodiment, the front end 

9 service 30 may be an Internet web browser. Alternatively, the front end service 30 may be a web 

1 0 application or a port monitor. The job request 32 may contain detailed information abouthowthe 

11 job is to be executed, and may be formatted according to the job definition format standard. 

1 2 Alternatively, the j ob request 3 2 may include only basic information, which will be used by another 

1 3 component to finalize the j ob defmition, or work flow. Finally, the job request 32 may include the 

1 4 content, or job, that is to be processed. The content could be one or more digital fdes, text fdes, 

1 5 and other files. The front end service 30 is coupled to a communications network 3 5 , which may 

16 be the hitemet or a local area network, for example. Coupled to the communications network 3 5 

17 is a service center 40 that links one or more processors 80i to the communications network 35 . 

1 8 Each of the processors 80, may include a cache 8 1 , that may be used to store information related 

19 to ajob request 32, includinginformationrelatedtojob tickets. In an embodiment, the service 

20 center 40 may be an hitemet web site that includes data storage and control fimctions. hi another 

21 embodiment, the service center 40 is a node in a local area network. 

22 The service center 40 allows a broad spectrum of communications between entities coupled 

23 to the service center 40. In particular, the service center 40 allows different e-services to interact 

24 programmatically with one another using specific protocols and generic protocols (e.g., TCP/IP). 

25 This programmatic interaction allows different services and processes that are coupled to the 

26 networkto exchange data and files, and to modifythe dataandfiles. The programmatic interaction 

27 may be completed by use of a remote procedure call (RPC) between entities coupled to the service 

28 center 40 . Other methods for providing the programmatic interaction include CORB A, UDDI, and 

29 e-speak. 
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1 Figure 4 is a diagram of the service center 40. The service center 40 includes a service bus 

2 4 1 in communication with the communications network 3 5 and the processors 8 Oi of Figure 3 . 

3 Coupled to the service bus 41 is aj ob store 5 0, a job ticket service 60, a work flow controller 70, 

4 an optional bidding service 90, an authorization server 92 and an authentication server 94. The job 

5 store 50 may store one or more job content files 5 Ij. The job ticket service 60 may control one 

6 or more j ob tickets 6 1 The work flow controller 70 may use one or more agents 7 1 , to control 

7 processes on the service bus 41 . 

8 The job store 50, job ticket service 60 and work flow controller 70 function to accept 

9 information from the clients 3 1 , and to use the information to control the actions of the processors 

10 80;. The processors SOiperforms specific tasks or processes as determined by the service center 

11 40. 

1 2 The j ob store 5 0 may be a node on the service bus 4 1 , and may include programming to 

1 3 allowthe job store 50 to carry out its functions. The job store 50 may be used to store the content 

14 51, which may be in the form of one or more large files. In the context of printing a document using 

15 a service or process coupled to the service bus 41 , the job store 50 may store the document 

1 6 content in one or more PDF files, for example. The content 5 1 may include graphics and text. The 

17 contentSl for a specific document may include several files. For example, a brochure may have 

1 8 a separate file for the cover and another file for the inside pages. Text for the inside pages may be 

19 in one file and hnagesinyet another file. The content 51 may also include links to other resources 

20 or entities on the service bus 4 1 . The j ob store 50 provides for mass storage of the content 5 1 , so 

21 that a user (client 3 1 or processor 80) does not have to provide the mass storage required for the 

22 job content 5 1 . By using the mass storage capabilities of the j ob store 50, the content 5 1 may be 

23 made to persist in the network 20, and may be made accessible to users at any time. The job store 

24 50 also manages and controls the content so that the user (client 3 1 or processor 80) does not have 

25 to manage the content 5 1 . Management fimctions include maintaining configuration or version 

26 control of the content 5 1 , controlling access to the content 5 1 , and maintaining the content 5 1 in 

27 storage. 

28 Thejob ticket service 60 holds job tickets 61 . Thejob ticket service 60 controls access 

29 to and may manage configuration of thejob tickets 6 1 . For example, the j ob ticket service 60 may 

30 allow users (clients 3 1 i and processors 80,) to access a portion or branch of a job ticket 61 rather 
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1 than passing the j ob ticket 6 1 among muhiple users. Access to the j ob ticket portion may be 

2 effectuated by use of an application programming interface, a scriptable interface, or a similar 

3 feature. As noted above, the job ticket 61 does not include the content 5 1 (e.g., the graphical and 

4 text files of a document), but the job ticket 61 relates to content 51 (e.g., aPDF file) storedin the 

5 j ob store 50. The user does not have to manage storage of the j ob content or to know which j ob 

6 store 50 holds the job content. The job ticket service 60 instead passes a reference in the job 

7 ticket 61. This allows multiple clients 31 and processors 80^ to access the content 51. 

8 Furthermore, the content 5 1 may relate to more than one j ob ticket 6 1 . The j ob ticket service 60, 

9 and its interrelationships with other entities coupled to the service bus 4 1 , will be described later 

10 in detail. 

11 Some job tickets 61 may be accessed by multiple processors 80, in either serial, 

1 2 overlapping, or simultaneous fashion. The mxiltiple access processing could result in problems with 

13 use ofthejob ticket 61. For example, a first processor may acquire thejob ticket 61 (oraportion 

14 or branch thereof), and perform a process specified in the work flow, which may modify the 

1 5 branch. Such modification may be to indicate a branch as complete, use up input resources, or 

1 6 create new output resources, for example. A second processor could attempt to acquire the 

17 branch, butmightnot"know"thatthefirstprocessorhadmodified the branch. Altematively, iftwo 

1 8 processors compete for the same branch, a deadlock situation might occur. 

1 9 One solution to the above problems may be to lock the job ticket 6 1 whenever aprocessor 

20 80 acquires thejob ticket 61. Unfortunately, locking thejob ticket 61 may prevent concurrent or 

21 parallel processing and may slow down completion of the job request 32. 

22 Thejob ticket service 60 shown in Figure 4 overcomes these and other problems by having 

23 the capability to lock the job ticket 61 at the branch level. The branch locking may be 

24 accomplished by one of several methods. The work flow controller 70 may assign one or more 

25 specific processors 80, to perform the tasks identified with the branch to be locked. Where only 

26 one processor 80 is authorized access to the branch, branch lockmg may not be required. Where 

27 more than one processor 80 is authorized access to the same branch, the j ob ticket service 60 may 

28 lock the branch when one of the authorized processors 80 actually acquire the branch. 



HP:10005667-1 



9 



1 If the work flow controller 70 has not assigned processors SOj to branches (i.e., any 

2 processor 8 0 may access a branch at any time), the j ob ticket service 60 may lock the branch when 

3 a processor 80 acquires the branch. 

4 The job ticket service 60 may lock the branches by setting a lock/unlock flag for each 

5 branch. Processors 80, accessing the j ob ticket 6 1 may then review the lock/unlock flag status to 

6 determine if the branch may be accessed. In some circumstances, the job ticket service 60 may 

7 allow access only to those branches that are unlocked. A processor 80 that has completed a task 

8 defined by the branch may need to have the branch unlocked in order to modify the branch. 

9 The work flow controller 70 may be used to create the] ob tickets 6 1 that are stored in the 

10 j ob ticket service 60. The work flow controller 70 may review the j ob requests 32 submitted by 

1 1 theclients31,andmaythenuseajobtickettemplatetopreparethejobticket61. Theworkflow 

12 controller 70 may then send the job ticket 61 to the job ticket service 60 for storage and 

13 processing. 

1 4 The work flow controller 70 also controls completion of tasks among the processors 80i. 

15 In an embodiment, the work flow controller 70 determines which of the processors SO^ have the 

1 6 necessary and available resources to begin the processes listed in a specific job ticket 6 1 . The 

1 7 work flow controller 70 then designates the appropriate processors 80; to complete the tasks 

1 8 referenced by the j ob ticket 6 1 . For example, if a j ob ticket 6 1 1 requires color printing, the work 

1 9 flow controller 70 may determine that only processor 8O3 is a color printer with the capacity to 

20 begin the job specified in the job ticket 61 1. This embodiment in which the work flow controller 

21 70 determines which processors 80, to assign to a specific job ticket 61 may be especially 

22 appropriate when the network 35 is a local area network and all processors 80, are directly 

23 coupled to the local area network 35. 

24 Alternatively, the work flow controller 70 may receive bid information from Intemet- 

25 connected processors 80, and may use the bid information to select the processors 80, to complete 

26 the job request 32. 

27 The work flow controller 70 may also be used to designate the various nodes, input and 

28 output resources, and other features ofthe node tree used to complete thejob request. Thatis,the 

29 work flow controller 7 0 may be used to create a construct, or work flow, such as the node tree 

30 10 shown in Figure 2. To accomplish these tasks, the work flow controller 70 may include one or 
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1 more agents 7 1 i that write a j ob definition file, based on control data contained in the j ob request 

2 32. Alternatively, a separate management information system (not shown) may be used to create 

3 the nodes, and to control flow of tasks to the processors 80^ and other entities. In yet another 

4 embodiment, the job defmitions maybe written by the client 3 1 that originated the job request 32. 

5 Referring again to the node tree 1 0 of Figure 2, many output resources of the individual 

6 nodes serve as input resources for other nodes. These other nodes may not be able to begin 

7 executing until all input resources are complete and available, which means that the nodes may need 

8 to execute in a well-defined sequence. For example, a process for making plates will produce 

9 press plates as an output resource that is required by a printing process. In the hierarchical 

1 0 organization of the node tree 1 0, nodes that occur higher in the node tree 1 0 represent higher-level, 

1 1 more abstract operations, while lower order nodes represent more detailed, specific processes. 

12 Moreover, nodes near the top of the node tree 10 may represent only intent regarding the 

1 3 components or assemblies that comprise the product, and lower level nodes provided the detailed 

14 instructions to a processor 80 to perform a specific process. 

1 5 Because two node trees may not be similar, the work flow controller 70 may determine 

1 6 processes to be completed, the order in which the processes are completed, and the processors 

17 SOj that are to complete the processes. The work flow controller 70 may use the agents 71 to 

1 8 determine an actual work flow, considering factors such as control abilities of the processors that 

19 complete the processes, transport distances between processors, load capabilities of the 

20 processors, and time constrains in the j ob request, for example. The agents 7 1 may define the 

2 1 overall process using serial processing, which involves subsequent production and consumption of 

22 resources by the processors 80j, overlapping processing, which involves simxiltaneous consumption 

23 and production of resources by more than one processor 80, parallel processing, which involves 

24 sharing resources among processors 80i, and iterative processing, which involves a back and forth 

25 processing scheme to develop resources. 

26 In determining which of the processors 8 Oi to assign to complete a particular j ob request, 

27 the work flow controller 70 may poll processors 80, that are coupled to the service center 40. As 

28 noted above, the processors 80, may be coupled directly to the service bus 4 1 , or may be coupled 

29 indirectly through another communications bus, such as the Internet, for example. The polling may 

30 occur whenever ajob ticket 61 is created by thejob ticket service 60. Alternatively, the polling 
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1 and corresponding information collection may occur on a periodic basis, and the work flow 

2 controller 70 may store information related to the processors 80i. 

3 As an alternative to polling, processors 80, coupled to the service center 80 may monitor 

4 the job ticket service 60. The job ticket service 60 may periodically post, in a bulletin board 

5 fashion, for example, notices for j ob tickets that are available for processing. The processors 80, 

6 may then submit a bid for the tasks and processes defined in the j ob ticket notice. The work flow 

7 controller 70, or the separate, optional bidding service 90, may review the bids, and determine 

8 which single processor 80; or combination of processors 80 would be best suited to complete the 

9 tasks and processes defined in the j ob ticket notice. 

1 0 The service center 40 may include several features to provide security and to control access 

11 to the job ticket 6 1 . As discussed above, the j ob ticket service 60 may include a provision for 

1 2 branch locking. In addition, servers may be used to authorize and authenticate a processor 80 and 

13 maintain the authorization and authentication during completion of a job request 32. The 

14 authentication server 92 receives authentication information from a processor 80 and the 

1 5 authorization server 94 uses the information to check authorization fiinctionahty . The authorization 

16 or access rights of the processor 80 may be carried as a part of the job ticket 6 1 . The servers 92 

1 7 and 94 may be hardware devices, but need not exist in the same hardware platform, and the 

1 8 servers 92 and 94 need not be tightly coupled. Alternatively, the fimctions of the servers 92 and 

19 94 may be performed in programming stored in one of the components of the service center 40, 

20 such as the work flow controller 70, for example. Using the above-described features, the service 

21 center 40 may provide trusted authentication information about the processor 80 to the 

22 authorization server 94, and the authorization server 94 then performs its authority check fonctions. 

23 The j ob ticket 6 1 may be signed with an industry standard public key encryption message 

24 digest (MD) signature, and may be protected by a public key encryption system. Hence, any user 

25 that has the public key may validate the job ticket 6 1 without having to communicate with the 

26 authentication server 92. These features reduce commimication between distributed server 

27 applications. The features also allow the job ticket 6 1 to be passed from one processor 80 to 

28 anotherprocessor 80, maintaining secvirity, without corntnunicating with the service center 40. 

29 In an alternative embodiment, the job ticket 6 1 holds authentication/access data, allowing 
3 0 controlled access within the service center 40 infrastructure. Resources may be protected by 
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1 passwords and other mechanisms. Access to the job ticket 61 may be similarly protected. 

2 Furthermore, processors 80, with access authorization may have such access authorization invoked 

3 by listing the processors in the j ob ticket. The listing may be effectuated by recording a network 

4 address for the processors 80,, for example. The network address may be incorporated in the bid 

5 information recorded in the j ob ticket 6 1 . 

6 Although the above description refers to development by the work flow controller 70, other 

7 components in the network 20 may be used to develop an overall work flow to complete the j ob 

8 request 32. For example, the job ticket service 60 maybe used to develop the overall work flow. 

9 As discussed above, the bidding service 90 may be used to receive bid information from 

1 0 processors 80, coupled to the service center 40. The processors 80 submit bids in response to 

1 1 posting of j ob ticket notices at the service center 40. In an embodiment, the j ob ticket notice is a 

12 separate object stored in the service center 40. In another embodiment, the job ticket 61 itself 

1 3 serves the notice function. The work flow controller 70 may post the j ob ticket notices after receipt 

14 of thejob request 32. Whetherthe bidding service 90 orthe work flow controller 70 receives the 

15 bids, the bid evaluation and selection process may be the same. 

1 6 The j ob ticket notice posted by the work flow controller 70 may include specific tasks or 

17 processes (branches) that must be completed to complete thejob request 32 (see Figure 7). A 

1 8 simple j ob request 32 may have only one branch. More complex job requests 32, such as thejob 

1 9 request illustrated in Figure 2 (i.e., print a brochure) may have many branches. Furthermore, some 

20 branches may be so interrelated that they can only be completed in a specific sequence, while other 

2 1 branches can be completed in a parallel or an overlapping fashion. This interrelationship may often 

22 be the resvilt of one branch producing an output resource that is an input resource for one or more 

23 other branches. The j ob ticket notice may include descriptions of specific branches and their 

24 interrelationships in sufficient detail to allow the processors 80, to bid for completion of the 

25 branches. The job ticket notice may persist in the service center 40 for a specified time to allow 

26 the processors 8 0 to send bids. The time may be a set value (e.g., one hour) or may be based on 

27 a completion deadline specified in thejob request 32. 

28 The bidding service 90 may select bids 9 1 from the processors 80, based on set criteria. 

29 For example, thejob request 32 may specify niiiumum performance requirements (e.g., amaximum 

30 cost and a completion deadline). The bidding service 90 may reject any bids that fail to satisfy the 
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1 mmimiim performance requirements. Where the work flow controller 70 has established multiple 

2 branches, each such branch may include minimum performance requirements. The branch-specific 

3 performance requirements may be established by the work flow controller 70 based on overall 

4 performance requirements for the job ticket 6 1 . A processor 8 0 that bids on a particular branch 

5 may be rejected by the bidding service 90 if the processor 80 fails to meet the minimirai 

6 performance requirements. 

7 If the client 3 1 does not specify any minimum performance requirements, the bidding 

8 service 90 may apply a standard set of criteria (e.g., an industry standard). In addition, the bid 

9 must satisfy any requirements for producing output resources. In this way, bids that are made in 

1 0 error, or that would otherwise likely be rej ected, can be screened out. For example, a bid for 

1 1 printing inside pages of the brochure may indicate a one year completion date. Such a bid may be 

12 rejected, even in the absence of any specified performance requirements from the client 3 1 . 

13 In addition to submitting performance reqiiirements, the client 3 1 may specify an evaluation 

1 4 algorithm for evaluating bids. For example, the client 3 1 may specify that cost is to be weighted 

1 5 twice as much as any other performance requirement. 

16 In the absence of a client-specified evaluation algorithm, the bidding service 90 may apply 

17 a standard evaluation algorithm in order to rank bids for each branch in the work flow. The 

1 8 evaluation algorithm may apply weighting criteria, or may apply a default rule. For example, bids 

1 9 may be ranked based on a maximum score, where points are awarded for cost estimates below 

20 a maximum and for completion times below a maximum. Once the evaluation algorithm has been 

2 1 applied, the bidding service 90 ranks the bids for each branch. If only one processor 80 survives 

22 the process, that processor 80 may be automatically selected and assigned to the branch. If 

23 multiple processors 80; survive, the bidding service 90 may provide a list of such processors 80 

24 to the work flow controller 70, which will then select the processors 80 to be assigned to the 

25 branches. Alternatively, the list may be provided to the client 3 1 , and the client 3 1 may select the 

26 processor(s) SOj to complete the tasks defined in the work flow. 

27 The work flow controller 70 may associate winning bids with corresponding branches, and 

28 may store the bid information with the j ob ticket 6 1 . The stored bid information may include 

29 identification information that allows the authorization server 94 and the authentication server 92 

30 to permit access to job ticket branches or to the entire job ticket 6 1 . Because the bid information 
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1 isstored withthejobticket61, aprocessor 80 may access those branches for which the processor 

2 8 0 is authorized access without having to communicate directly with the job ticket service 6 1 . This 

3 feature allows the job ticket 60 to be passed from one processor 80 to another processor 80, 

4 which improves processing time and efficiency. 

5 In an embodiment, the work flow controller 70 accesses control data of the j ob ticket 6 1 

6 to determine which processor(s) 80, should be assigned to the specific task identified in the j ob 

7 ticket. The work flow controller 70 may also identify which of the processors 80 would be able 

8 to meet the criteria specified in the control data, and may provide a list of such processors 80 to 

9 the client through the front end service 30. The client 3 1 may then select a processor(s) 80 from 

10 the list. 

11 In an embodiment, the job ticket service may comprise a sequence of programming 

1 2 instructions that are recorded on a machine readable medium, such as a CD-ROM, for example. 

13 A computer may read the programming instruction and execute processes to provide the functions 

14 of the job ticket service, including using a job ticket to store bid information. 

15 Figure 5A illustrates an exemplaryjob ticket 61. Thejob ticket 61 may include two parts. 

16 A first part includes a framework 62 and an optional client extension 64. The framework 62 

1 7 includes information, files and programming necessary to control tasks defined in the j ob ticket 6 1 . 

1 8 The client extension 64 may include information related to a specific client (machine) and to a user 

19 of the machine . A second part includes a security module 67 that protects the j ob ticket 6 1 from 

20 unauthorized access. 

2 1 The framework 62 may include a j ob identification (ID) 63 , a service ID 65 , a task section 

22 68, and control data section 69. Thejob ID 63 includes a reference to a specific job, or content 

23 51 that is stored in thejob store 50. Thejob ID 63 also includes a reference to a particular job 

24 store 5 0 that is used to store the content 5 1 . An entity that acquires a reference to the job ticket 

25 61 can use thejob ID 63 to access the corresponding content 5 1 . Thus, the network 20 shown 

26 in Figure 3 may include multiple j ob stores 50, and the j ob ID 63 may be used to correlate the j ob 

27 ticket 6 1 to a specific job store 50. The service ID 65 identifies a specific job ticket service 60 that 

28 stores thejob ticket 6 1 . For example, the network 20 may include multiple job ticket services 60 

29 (not shown in Figure 3). The service ID 65 is used to correlate the job ticket 61 to the appropriate 

30 job ticket service 60. 

HP; 10005667-1 15 



1 The tasks section 68 may include branch definitions, and other information needed to 

2 control completion of the branches. The tasks section 6 8 may be structured so that each branch 

3 or node in a node tree is represented by one or more branches 66^ in the tasks section. In this 

4 embodiment, eachnode in the node tree (e.g., the node tree 1 0 of Figure 2) can have associated 

5 with the node, the description 95, resources 96, lock/unlocked flag 97, and security features 99. 

6 In this way, the job ticket 61 reflects a hierarchical database structure. 

7 The control data section 69 includes the specific instructions, parameters, and criteria for 

8 completing the task identified by the j ob ticket 6 1 . Control data in the control data section 69 may 

9 also be associated with each node in a node tree. 

1 0 The security module 67 controls access to a specific j ob ticket. The security module 67 

1 1 may be implemented using standard encryption and access techniques, including public/private key 

12 infi-astructures, for example. 

1 3 The client extension 64 may contain "custom" information, such as user age, credit card 

1 4 number and zip code. Information provided in the cUent extension 64 may be protected by use of 

15 a public key signature, or similar feature. Hence, all client extension information will automatically 

16 be included in a Message Digest Protocol (MDP) and will affect the signature of the j ob ticket 6 1 . 

17 With the above-describe job ticket architecture, many Internet-related security issues are 

18 addressed, including IP spoofing, time controlled sessions, job ticket alterations, varying 

19 authorization levels, and client-dependent persistent data storing. 

20 The j ob ticket 6 1 shown in Figure 5 A may be used to refer to a specific content 5 1 in the 

21 jobstoreSO. Alternatively, multiplejob tickets 61 may be used to refer a specific content 5 1 , or 

22 onejob ticket 61 maybe used torefer to multiple contents 51. Thus, forexample, onejobticket 

23 61 may specify a repetitive printing task to be completed on similar documents, each of which has 

24 a different content 5 1 . 

25 Using the network 20 showninFigure 3, and the correspondingjob ticket shown in Figure 

26 5 A, a client 3 1 may request and have completed many different electronic services . For example, 

27 the client 3 1 may use the network 20 as an e-mail application. 

28 Figiire 5B shows the tasks section 68 in detail . The tasks section 6 8 may include one or 

29 more branch descriptors 66 that include information related to processing for that branch. A 
3 0 description segment 95 may define the tasks to be completed for each branch. Alternatively, the 
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1 description segment 95 may provide a link, or handle, to a file that contains the branch description. 

2 The resources segment 96 lists input and output resources associated with the tasks defined for the 

3 branch. The lock/unlock flag segment 97 allows a flag to be set to lock and unlock a branch. A 

4 bid information segment 98 includes bid information gathered, for example, by the bidding service 

5 90. The bid information 98 may include detailed information such as the IP address of the 

6 processors authorized access to the branch, estimated performance information (e.g., estimated 

7 cost, delivery time), and other information. Alternatively, the bid information 98 may contain a link 

8 to another file containing the detailed bid information. The security segment 99 may indicate 

9 authorized security levels, and may be used as part of a public key/private key infrastructure. 

1 0 Figure 5C illustrates an embodiment of the control data section 69. The control data 

1 1 section 69 includes a client address, which may be a machine address, such as an hitemet protocol 

12 (lP)address. An expiration date/time segment may be used to terminate active status of the ticket 

13 61. Once terminated, the ticket may be deleted fi-om the j ob ticket service, and the corresponding 

1 4 content 5 1 may be de-referenced such that the content 5 1 is not referenced by the j ob ticket 6 1 . 

1 5 This feature may help eliminate stale data, and fi-ee up resources for other job requests 32. Finally, 

16 the control data section 69 may include specific performance requirements, such as cost an 

1 7 delivery, warranty, required materials, price reductions based on quantity, and other requirements, 

18 for example. 

1 9 The use of job tickets as XML obj ects allows clients to define databases, and to store data 

20 through the job ticket service 60 and the job store 50. The databases maybe used to hold contact 

21 lists, addresses, and other personal data. The databases may also be used to store any other 

22 generic data. The databases could then be used in conjunction with a variety of e-services 

23 provided by the processors 80,. For example, an e-mail processor 80 that provides e-mail services 

24 may be used in conjunction with apersonal contact list to send e-mail messages, transfer electronic 
2 5 files, or to establish a chat room. The e-mail processor 80 may access the contact list at predefmed 

26 intervals to send e-mail messages to a select group of e-mail addressees. Furthermore, because 

27 the service center 40 provides a single portal to processors 80 that are coupled to the 

28 communications network 35, the chent 3 1 need not have any knowledge of the database structure, 

29 or the processing requirements of the processors 80. 
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1 In the specific application of the generic XML database to an e-mail service, the client 3 1 

2 may have established, as a generic database, a list of e-mail contacts. The contacts database may 

3 then be stored in the job store 50 as a content file 5 1 . A corresponding job ticket 6 1 may be 

4 stored at the j ob ticket service 6 1 . The job ticket 6 1 includes control data needed to send and 

5 receive e-mail through the service center 40. Furthermore, thejob ticket 61 serves as a pointer 

6 to data in the content file 5 1 . Inparticular, thejob ticket 61 may store XML data that is related 

7 to other data stored in the content file 5 1 . 

8 Alternatively, thejob ticket 61 may store the contacts data. This alternative takes 

9 advantage of the factthat thejob ticket61 includes a vocabulary that can be extended to include 

1 0 the contact data, and that the vocabulary can be further extended to include properties for each 

11 contact in the contact data. For example, thejob ticket 61 may specify that a contact is a busuiess 

1 2 contact or a personal contact. Other properties may also be included, such as whether the contacts 
~ 13 in the contact database use mobile phones, land line phones, facsimile machines, and e-mail 

14 addresses. 

15 Theuseofthejobticket61 also allows for parsing, searching and updating the contacts 

16 database. For example, the client 31 may desire to search the contacts database for phone 
2 17 numbers for all persons whose first name is Joe. This search functionality is included in thejob 

1 8 ticket 6 1 , and allows the j ob ticket service 60 to provide the client with a list of phone numbers for 

1 9 all entries in the contacts database where the person' s first name is Joe. That is, the contacts 

20 database includes entries having the property of Joe, and thejob ticket service is able to search the 

21 contacts database for this property, and to return a list of those entries to the client 3 1 . 

22 The properties function of the job ticket 61 also allows thejob ticket service 60 to control 

23 specific tasks desired by the client 3 1 , or to indicate to the client that a desired task caimot be 

24 completed. Staying with the example of the contacts database, the client 3 1 may desire to send 

25 a facsimile transmission to all entries in the contact hstthat have a specific zip code. Thejob ticket 

26 service 60 can search the contacts database by properties, looking for zip code. The j ob ticket 

27 service 60 can also search the contacts database to determine if any entry does not have a facsimile 

28 machine. For those entries that do not have a facsimile machine, thejob ticket service 60 can 

29 originate a message to send back to the client 3 1 , informing the client 3 1 that the facsimile 
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1 transmission was undeliverable. Using this functionality, the client 3 1 need not know anything about 

2 the intended recipients of the facsimile transmission. 

3 Returning to the example of an e-mail service, at the client 3 1 , an e-mail application may 

4 be launched in order to send an e-mail message, using the Internet, to one or more contacts in the 

5 contact database. However, the client 3 1 need not subscribe to any one Internet service provider. 

6 Instead, the service center 40 determines which processor 80 best suits the client's needs for 

7 sending the e-mail message. That is, the service center 40 may select a e-mail service provider (a 

8 processor 80) to send the e-mail message to a chosen destination address. Furthermore, the 

9 service center 40 may determine, based on information maintained in the contact database (i.e., the 

1 0 content 5 1 in the j ob store 5 0), which delivery options are desired by a user at the destination 

1 1 address. For example, the destination address user may desire that all e-mail messages be sent to 

12 an e-mail box, or that an alert be provided whenever an e-mail message is sent. These delivery 

1 3 features may be stored in the contact database. Alternatively, the delivery features may be stored 

14 in a separate database (content file 5 1) in the job store 50, and the service center may retrieve 

1 5 information form this separate database when determining how to deliver the e-mail message. 

1 6 Specifically, the separate database may include a variety of users, along with the user ' s Internet 

1 7 address. By comparing the Internet address provided with the out going e-mail to the Internet 

1 8 addresses in the separate database, the service center 40 can determine desired delivery options 

1 9 of the addressee. This process for determining delivery options is transparent to the client 3 1 that 

20 originated the e-mail message. All that the client 3 1 need know is the contact information (e.g., the 

21 Internet address). 

22 The client 3 1 may use the job ticket service 60 to specify a number of performance features 

23 related to the e-mail service. For example, the chent 3 1 may want the service center to attempt a 

24 specified number of delivery attempts, and if delivery does not occur, to send a return message to 

25 the client 3 1 indicating non-delivery of the e-mail message. 

26 As noted above, the j ob ticket 6 1 , in conjunction with other components of the service 

27 center 40, may also be used to create a persistent, generic obj ect-based data structure, such as an 

28 XMLdatabase. An example ofthe use ofajob ticket 61 for this purpose is illustrated in Figure 

29 5D. The job ticket 6 1 includes a contacts list 84, which may be in the form of an XML database, 

30 or some other generic database. The contacts list 84 may include a structure with entries for 
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1 business 8 5 and personal 86 use . The business 85 and personal 86 contacts structures may include 

2 entries of individuals 87, as shown. Each of the entries 87 may include specific properties, as 

3 defined above. In addition, or alternatively, each of the entries 87 may include links to other 

4 databases that provide additional information and properties about the individual. 

5 While the use of the j ob ticket 6 1 as a XML database has been described with reference 

6 toane-mailandmessagingservice,thejobticket61 is not so limited. Any data that is capable of 

7 being stored in a database may be accesses and controlled using the job ticket 61. 

8 The features described above, and shown in Figures 5 A-5D may be replicated in another 

9 embodiment of a j ob ticket 6 1 in which all data related to a specific node or branch is located with 

1 0 that node or branch. Using the example node-tree 1 0 shown in Figure 2, each node (branch) may 

1 1 include detailed information and features such as resources, authorized processors 80;, lock/unlock 

12 flag, bid information, branch description, and other information. 

13 Figure 6 is a diagram of ftmctions of the job ticket service 60. The primary functions of the 

14 j ob ticket service 60 are to store 73 the j ob tickets 6 1 ; and to provide access 75 to the j ob tickets 

15 61 to users such as the client 3 1 and to the processors 80. To accomplish these storage and 

1 6 access functions, thejob ticket service 60 may create ajob ticket reference 72 and ajob resource 

17 reference 74. Thejob ticket service 60 also controls job content access 76, updates 77 thejob 

1 8 tickets 6 1 as processes are completed and reported by the processors 80;, completes thejob ticket 

19 61 and reports 7 8 when all processes are completed for a specific j ob ticket 6 1 , and provides an 

20 approval process 79 to allow a chent 3 1 to approve completion of the tasks designated in the j ob 

21 ticket 61. 

22 Thejob ticket reference 72 includes a specific reference to a corresponding job ticket 61 j. 

23 The j ob ticket reference 72 may be used by the j ob ticket service 60 to allow one or multiple 

24 processors and chents to access thejob ticket 61. That is, instead ofpassing thejob ticket 61 to 

25 a processor 80, thejob ticket service 60 passes thejob ticket reference 72. With thejob ticket 

26 reference 72, the processor 80 may access all or apart of ajob ticket 6 1 so that the processor 80 

27 may complete one or more processes. Unlike conventional job ticket services, the job ticket 

28 service 60 retains thejob ticket in storage 73, and only permits users (clients 3 1 and processors 

29 8 0) to access the j ob ticket 6 1 . This feature allows multiple processors 80 to simultaneously 

30 complete processes for the specific job request 32 related to the job ticket 6 1 . 
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1 The job ticket service 60 may also create a resources reference 74, and may provide the 

2 resources reference 74 to the processors 80 and the clients 3 1 in amanner similar to that of the j ob 

3 ticket reference 72 . As noted above with the description accompanying Figure 2, the resources 

4 may include physical devices and materials, and may include digital files . Use of the resources 

5 reference 74 may simplify data included in the job ticket 61. 

6 Alternatively, information contained in the resources reference 74 may be included in the 

7 j ob ticket 6 1 , or may be included in other files accessed by the clients 3 1 and the processors 8 0 . 

8 Figure 7 is a diagram showing operation of selected fimctions of the job ticket service 60. 

9 As shown in Figure 7, the job ticket service 60 includes a job ticket 61i, which may be a 

1 0 programming obj ect such as that represented in Figure 2, and described above. The j ob ticket 6 1 1 

1 1 is shown supplied to the job ticket service 60 by the client 3 1 1 . The client 3 1 1 may be a networked 

1 2 computer or similar device that is capable of transmitting the digital information representing the j ob 



1 3 ticket 6 1 1 to the j ob ticket service 60. To ensure the j ob ticket 6 1 arrives at the j ob ticket service 

14 60, the job ticket 61 1 may contain a reference to the job ticket service 60, such as the service ID 

15 65 illustrated in Figure 5B. The service ID 65 may include a network address of the job ticket 

1 6 service 60. For example, the service ID 65 may include a universal resource locator (URL) if the 

17 job ticket service 60 is an Internet web site. 



18 Also shovsrninFigure7 are client 3 l2andprocessors 80i - 80^. The processors SOj - 80^ 

1 9 may include networked resources such as networked printers, electronic-commerce entities, such 

20 as Internet web sites, and "brick and mortar" entities, such local print shops that are coupled to the 

21 job ticket service 60 using the service bus 41 . 

22 The client 3 1 generates a j ob request 3 2 (content 5 1 and j ob ticket data) . Using the front 



23 end service 30 (not shown in Figure 7) and the service bus 4 1 , the client 3 1 1 sends the job ticket 

24 data to the job ticket service 60 and the content 5 1 (not shown in Figvire 7) to the job store 50. 

25 The job ticket service 60 may pass the job ticket data to the work flow controller 70, which will 

26 create a j ob ticket 6 1 . The content 5 1 1 and the j ob ticket 6 1 1 are related by the j ob ID 63 . The 

27 j ob ID 63 also includes an identification of the j ob store 5 0, and a location within the j ob store 50 

28 in which the content 5 1 1 is stored. In an alternate embodiment, the content 5 1 1 may be stored at 

29 the client 3 1 1 , and may then be accessed by other users through the service bus 4 1 and the front 

30 end service 30. 
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1 The j ob ticket 6 1 1 specifies processes that must be completed to finish the j ob request 32. 

2 As noted above, Figure 2 illustrates processes required to print a brochure, including the inside 

3 pages and the cover. More that one processor may be required to complete such a j ob request, 

4 orto completethejobrequestinthemostcost-efficientand/ortimelymanner. The workflow 

5 controller 70 (not shown in Figure 7) can determine which of the processors SOi-SOn should 

6 complete a specific process, and, if necessary, the order in which such processes should be 

7 completed. The work flow controller 70 may poll the various processors 80i to determine which 

8 may be used to complete the job request. The work flow controller 70 may then notify selected 

9 processors 80, that a job request has been registered with the job ticket service 60. 

1 0 For each job ticket 6 1 , received, the j ob ticket service 60 creates a reference 72, to the 

11 jobticket61i. Theprocessor80imayrequestaccesstothejobticket61 in order to complete one 

12 or more processes, hi response, the job ticket service 60 provides the processor 80i with the job 

1 3 ticket reference 72i. The job ticket reference 72i is then used as an index to the job ticket 6 1 1 . 

1 4 The job ticket reference 72 1 may also be provided to other processors, such as the processor 8 O2, 

1 5 and to other clients, such as the client 3 1 2. The processor 8O2 and the client 3 1 2 may then access 

16 the job ticket 6I1 at the same time as the processor 80 1 accesses the job ticket 6I1. This 

17 simultaneous access allows different processes to be completed in parallel. In the example 

1 8 illustrated in Figure 2, the processor 8O1 may complete some or all the processes for the inside 

1 9 pages, and the processor 8O2 may complete the processes for the cover. 

20 Figure 8 is a block diagram illustrating an example application of the control features of the 

21 job ticket service 60. The job ticket 6 1 1 is referenced to the job content 5 1 1 by the job ticket ID 

22 63 , and information related to the j ob ticket 6 1 1 and the j ob content 5 1 , is passed over the service 

23 bus41. Theprocessors 80,canaccessthejobcontent51i andthejobticket61iUsingtheservice 

24 bus 4 1 . In the illustrated example, the j ob ticket 6 1 j refers to a job request 32 to print a brochure 

25 using the processes outlined in Figure 2. The processor SOj is designated by the work flow 

26 processor 70 to produce the inside pages of the brochure and the processor 8O2 is designated to 

27 produce the brochure cover. The processor 8O1 passes a job ticket access request to the job 

28 ticket service 60. The access request may include security information that allows the processor 

29 8O1 to access the job ticket 61 1 and the corresponding content 5 1 1 or job. In response, the job 

30 ticket service 60 provides ajob ticket reference 62i that is used by the processor 8O1 to access 
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1 the job ticket 61 j. The processor 80i may use information in the job ticket 61 1 to access the 

2 content 51 1 stored in the job store 50. Since the processor 80 1 will produce only the inside pages, 

3 the processor 80 j will not need access to all the information contained in the job ticket 6 1 1. 

4 Furthermore, because the j ob ticket 6 1 1 remains in the j ob ticket service 60, other entities, such 

5 as the processor 8O2, may continue to access the job ticket. 

6 As the processor SOj completes various processes, the processor 8O1 may update the 

7 content 51i andthejobticket61i. Thus,thejobticket61i mayreflectthelateststatusofthejob 

8 request32. The status reports may indicate when a node in the node tree 10 is completed, when 

9 an interim deadline is completed, when another processor may be used to complete a process, and 

1 0 when all processing is complete. The status report may be included in a digital file that is used by 

1 1 the work flow controller 70, for example. The status report may also be included in a human- 

1 2 readable format, such as a pop-up window on a computer display screen. The processor 80, may 

1 3 receive the job ticket reference 72 1, and may complete all scheduled processes, returning the job 

14 ticket reference 72, to the job ticket service 60. The processor 8O1 may also send a copy of the 

15 j ob ticket reference 72 1 to the processor 8O2, so that the processor 8O2 may access the j ob ticket 

16 61,, and the content 5 1 , and produce the brochure cover. 

1 7 Figure 9 is a flowchart illustrating an operation 1 00 of the j ob ticket service 60 . The 

1 8 operation 1 00 is based on completing the inside pages nodes shown in Figure 2 . The operation 

19 100 may be at least partly under the control of the work flow controller 70, or some equivalent 

20 device. The operation 1 00 assumes that a j ob request 32 (j ob ticket data and content) have been 

2 1 passed to the service center 40, and that a j ob ticket service 6 1 has been created. The operation 

22 100 begins at start block 101. In review and assign processors block 105, the work flow 

23 controller 70 determines which processors 80; are able and available to complete the j ob. The 

24 work flow controller 70, or the optional bidding service 90 may use polling or bidding features to 

25 make the determination. If more than one processor 80 is available, and can satisfy the 

26 requirements of the j ob ticket 6 1 , the work flow controller 70 may assign one specific processor 

27 SOtothejob. Alternatively, the work flow controller 70 may pro vide a list of processors 80, to 

28 the client 3 1 , and allow the client 3 1 to select one or more processors 80j. 

29 Inrequest job ticket block 110, aprocessor 80, having been authorized access to a job 
3 0 ticket 6 1 , sends an access request to the j ob ticket service 60 using the service bus 4 1 . In block 
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1 1 15,thejobticketserviceverifiesthattheprocessor 80niayaccessthejobticket61. Accessmay 

2 be controlled by apassword, an identification, and a public key/private key security system, for 

3 example. In block 1 1 5, if the processor 80 is denied access, an error signal may be sent to the 

4 processor and/or the client 31, block 120. 

5 In block 11 5, if access is authorized, the job ticket service 60 provides the processor 80 

6 withacopyofthejobticketreference72correspondingtothejobticket61, block 125. Thejob 

7 ticket reference 72 allovv's the processor 80 to access thejob ticket at any time. By accessing the 

8 job ticket 6 1 at any time, the processor 80 is able to view an updated version of the j ob ticket 6 1 

9 as changes are made to the job ticket 61 by other entities, including other processors 80. 

1 0 In block 130, thejob store 50 provides access to thejob content 5 1 that is referenced by 

11 thejob ticket 61. Only that part ofthe content 51 that may be needed by the processor 80 may 

12 be supplied by the job store 50. For example, if the processor 80 is only to generate the inside 

1 3 pages of the brochure, the j ob store 5 0 may not provide access to the content required to produce 

1 4 the brochure cover. After receiving the j ob ticket reference 72 and the content 5 1 , the processor 

15 80 may perform one or more tasks using input resovirces to produce an interim or final output 

1 6 resource. With completion of each node in the node tree 1 0, the processor 80 may provide an 

17 input to thejob ticket service 60 to allow modification of thejob ticket 61, block 135. If the 

1 8 processor 8 0 completes all required processes, the processor 8 0 may provide a final status report 

19 to the j ob ticket service 60, block 140, along with any final modifications to thejob ticket 6 1 . 

20 In block 145, thejob ticket service 60 andthe work flow controller 70 determine if any 

2 1 additional tasking may be required. If additional tasks are required, the work flow controller 70 

22 will ensure the appropriate processors 80 are assigned, andthe operation returns to block 110. 

23 If no additional processes are required, the operation moves to block 1 50 and ends. 

24 Figure 10 is a flowchart illustrating the routine 105 for developing a work flow and assigning 

25 processors to the work flow. Theprocess starts in block 200. In block 205, the service center 

26 40 receives a job request 32. The job request 32 may specify performance requirements, 

27 resources, and other parameters, and may include content 5 1 , or a link to the content 5 1 . In block 

28 210, the work flow controller 70 defines a work flow to accomplish the tasks specified in thejob 

29 request 32. The work flow may be represented by a node tree, such as the node tree 1 0 shown 

30 in Figure 2. 
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1 In block 23 0, the work flow controller 70 generates a j ob ticket 6 1 using the information 

2 provided by the j ob request 32, the work flow generated in block 210, and an appropriate j ob 

3 ticket template. The job ticket 61 is then stored in the job ticket service 60. AnycontentSl may 

4 be stored in the job store 50. 

5 The work flow controller 70 or the j ob ticket service 60 may create a j ob ticket notice, or 

6 other obj ect, and may post the notice, block 250, at the service center 40 so that outside entities 

7 (e.g., the processors 80) may acquire sufficient information to bid on completion of the j ob ticket 

8 6 1 , or a branch 66 of the j ob ticket 6 1 . In an alternative embodiment, the j ob ticket 6 1 may be 

9 posted at the service center 40. If the job ticket 61 is posted, the job ticket 61 may include 

1 0 mechanism to limit access to the j ob ticket or to limit access to certain portions of the j ob ticket 6 1 . 

1 1 For example, the client extension 64 may not be accessible to the processors 80. 

12 In block 270, the service center 40 receives bids from specific processors 80 and in block 

1 3 290, the service center 40 evaluates the bids, hi block 295 , the service center 40 determines if the 

1 4 client 3 1 submitting the j ob request 32 intends to select the winning bid(s), or if the service center 

15 40 makes the selection. If the client is to make the selections, in block 300, the service center 40 

1 6 provides the bid information to the client 3 1 . Then, in block 3 05, the service center 40 receives 

1 7 the selections from the client 3 1 . If the service center 40 is to make the selections, in block 3 1 0, 

1 8 the service center 40 selects the wirming bid(s). In block 315, the service center notifies the 

1 9 winning processors. The service center may also store the bid information with the corresponding 

20 job ticket 61 . In block 320, the routine 1 05 ends. 

2 1 Figure 11 is a flowchart illustrating the sub-routine 2 1 0 for defining a work flow. The sub- 

22 routine210 starts in block 350. In block 3 55, the work flow controller 70 determines if the work 

23 flow will contain multiple branches. If the work flow will contain multiple branches, the work flow 

24 controller 70 defines the branches, block 360. In block 365, the workflow controller 70 selects 

25 a branch for which resources and processes are to be defined. In block 370, the work flow 

26 controller 70 defines input resources for a first process, or node. In block 375, the work flow 

27 controller 70 defines the tasks to be completed for the first process. In block 3 80, the work flow 

28 controller 70 determines the output resources of the first process. In block 3 85, the work flow 

29 controller 70 determines if another process is required for the work flow or branch. In no 
3 0 additional processes are required, the work flow controller 70 determines if another branch is to 
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1 be defined, block 390. If another branch is to be defined, the work flow controller 70 selects 

2 another branch, block 365, and the sub-routine 210 continues. If another branch is not to be 

3 defined, the sub-routine 210 ends, block 395. The results of the work flow definition may be 

4 incorporated into the job ticket 61 (see Figure 10, block 230). 

5 Figure 1 2 is a flow chart illustrating the sub-routme 25 0 of posting a j ob ticket notice or j ob 

6 ticket. The sub-routine 250 starts in block 400. In block 405, the work flow controller 70 

7 determines if the work flow associated with the job ticket 61 includes multiple branches. If the 

8 work flow does not include multiple branches, the work flow controller posts the j ob ticket notice 

9 listing the single branch, block 410. If the work flow includes multiple branches, the work flow 

10 controller 70poststhejobticketnoticewithmultiple branches, block 420. The sub-routine 250 

1 1 then ends. 

1 2 Figure 1 3 is a flow chart illustrating the sub-routine 290 for evaluating bids. The sub- 

13 routine starts in block 440. Inblock445,thebiddingservice90selectsafirstbidforanalysis. In 

1 4 block 45 0, the bidding service 90 determines if the chent 3 1 has suppUed any evaluation criteria or 

1 5 requirements. If the client has not supplied evaluation requirements, the bidding service 90 

1 6 compares the selected bid to a set of standard, minimum performance requirements, which may be 

1 7 industry-standard requirements block 45 5 . In block 460, the bidding service 90 determines if the 

1 8 bid meets the minimimi performance requirements. If the bid does not meet the minimum 

1 9 performance requirements, the bid is rejected, block 475. If the bid is rejected, the biddmg service 

20 90 determines if additional bids were submitted, block 495 . If additional bids were submitted, the 

21 bidding processor 90 returns to block 445 and selects the next bid for evaluation. 

22 In block 450, if the client 3 1 has supplied performance requirements, the bidding service 

23 90 compares the selected bid to the client-supplied performance requirements, block 465 . In 

24 block 470, the bidding service 90 determines if the selected bid meets the minimum criteria of the 

2 5 client-supplied performance requirements. If the minimum criteria are not met, the bidding service 

26 90 rej ects the bid, block 475 . 

27 In blocks 470 and 460, if the minimum criteria are met, the bidding service 90 determines 

28 if the cUent 3 1 has supplied an evaluation algorithm. If the client 3 1 has not supplied an evaluation 

29 algorithm, the bidding service applies a standard evaluation algorithm, which may be an industry- 

3 0 standard algorithm, block 485 . If the client has supplied an evaluation algorithm, the bidding service 
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1 90 applies the client-supplied evalxiation algorithm, block 490. The bidding service 90 may then 

2 store the results of the algorithm pending evaluation of all bids. 

3 In block 495, the bidding service 90 determines if any bids remain to be evaluated. If 

4 additional bids remain, the sub-routine 290 returns to block 445 , and the bidding service selects 

5 the next bid for evaluation. In block 495, if no additional bids remain for evaluation, the bidding 

6 service 90 ranks the bids, block 500. The sub-routine 290 then ends, block 505. 

7 Figure 14 is a flowchart illustrating the routine 130 for providing access to ajob ticket 61. 

8 Theroutine 130 begins in block 5 10. Inblock515,thejobticketservice 60 receives ajob ticket 

9 reference 72 from a processor 80, and retrieves the corresponding job ticket 61 , block 520. 
10 In block 525, the job ticket service 60 compares the processor identification to processors 



1 1 listed in thejob ticket 61 or branches 66 ofthejob ticket 61. Thejob ticket service 60 determines 

12 if the selected branches 66 are locked, block 530. If the selected branches 66 are not locked, the 

13 j ob ticket service 60 copies the selected branches 66 to the processor 80, block 535. In block 

14 550, the j ob ticket service 60 then determines if the selected branches 66 require locking. If the 

15 selected branches do not require locking, the routine 130 ends, block 560. Ifthe selected branches 

1 6 66 require locking, the job ticket service 60 locks the selected branches 66, block 555. The 

1 7 routine 130 then ends, block 560. 

1 8 In block 530, ifthe selected branches 66 are locked, the j ob ticket service 60 determines 

1 9 ifthe processor 80 intends to modify information in the selected branches 66, block 540. Ifthe 

20 processor 80 will not modify the selected branches 66, thejob ticket service 60 may provide an 

2 1 error message, block 545 . If the selected branches 66 will be modified, the j ob ticket service 60 

22 may unlock the selected branches 66. 

23 Figure 1 5 is a flow diagram of a method for allowing access to a j ob ticket 6 1 . The method 

24 may execute as part of the routine 1 15 shown in Figure 9. The method starts with block 600. In 

25 block 605, the authentication server 94 receives authentication information from a processor 80 

26 and retrieves a j ob ticket 6 1 corresponding to a j ob ticket reference 72 possessed by the processor 

27 80. At this stage of the process, thejob ticket 6 1 (excluding the public key signature field 67) 

28 contains two information fields, the framework 62 and the client extension 64. The framework 62 

29 contains information such as the service ID, client IP address, expiration date and time, and 
3 0 processor authorization, as previously described. The client extension 64 contains information such 
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1 as credit card number and zip code, also previously described. The information in the j ob ticket 

2 61 (excluding the public key signature field 67) is then, for example, optionally hashed using, for 

3 example, MD5 protocol, and encrypted with a public key encryption system, block 610, generating 

4 a hash number, block 615. Other hashing or encryption techniques may also be used. The hash 

5 number is representative of the specific information contained in the j ob ticket 6 1 . The hash number 

6 generated in block 6 1 5 is then encrypted using a standard pubHc key encryption system, block 620. 

7 Encrypting the hashnumberwithaprivate key prevents any user without knowledge of the public 

8 key from modifying the job information. Inblock625,thejobticket61 and the encrypted hash 

9 number are concatenated to generate the completed j ob ticket 6 1 . Hence, the completed j ob ticket 

10 61 information fields : 1 ) the framework 62, 2) the client extension 64, and 3) the public key 

1 1 signature (encrypted hash number) 67. The method then ends, block 630. 

12 In the illustrated embodiments, the service center 40, and its sub-components, including the 

1 3 work flow controller 70 and the j ob ticket service 60, for example, may be implemented as a single, 

1 4 special purpose integrated circuit (e.g., an ASIC) having a main or central processor section for 

1 5 overall, system-level control, and separate circuits dedicated to performing various different 

1 6 computations, functions and other processes under control of the central processor section. Those 

1 7 skilled in the art will appreciate that the service center 40 may also be implemented using a plurality 

1 8 of separate, dedicated or programmable integrated or other electrical circuits or devices (e.g., 

1 9 hardwired electronic or logic circuits such as discrete element circuits, or programmable logic 

20 devices such as PLDs, PL As, or PALs). The service center 40 may also be implemented using 

21 a suitably programmed general purpose computer, e.g., a microprocessor, microcontroller or other 

22 processor device (CPU or MPU), either alone or in conjunction with one or more peripheral (e.g., 

23 integrated circuit) data and signal processing devices. In general, any device or assembly of 

24 devices on which a finite state machine capable of implementing the flowcharts shown in Figures 

25 9-16 can be used as the service center 40, or its sub-components. 

26 The terms and descriptions used herein are set forth by way of illustration only and are not 

27 meant as limitations. Those skilled in the art will recognize that many variations are possible wdthin 

28 the spirit and scope of the invention as defined in the following claims, and their equivalents, in 

29 which all terms are to be understood in their broadest possible sense unless otherwise indicated. 
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